The Internet is used to share public information. Since it is an open system, it should not be used to share confidential information unless precautions are taken to protect the information by use of passwords, encryption and the like. Even so, if passwords are used, they can be determined by hackers. In the Internet, there are clients (typically personal computers with computer programs) and servers (server computers running computer programs that cause them to provide services to the clients). Typically computer programs used at clients and servers assume that their users are honest about their identity. Some client/server applications rely on the client to restrict its activities to those which it is allowed to do, with no other enforcement by the server. Strong authentication is highly desirable for transactions involving money, confidential data or both.
One way to improve the situation is to use dedicated authentication protocols and, if necessary, encryption protocols for verifying the authenticity of a party and for preventing unauthorised parties from obtaining access. In addition, these protocols can typically be used to verify the integrity of any information exchanged over a link so that a recipient can be certain that the data received have not been tampered with.
Kerberos is a protocol designed to provide strong authentication for client/server applications by using secret-key cryptography. At least two versions of Kerberos have been described, versions 4 and 5. The version 5 Kerberos has been described by J. Kohl and C. Neuman in “The Kerberos Network Authentication Service (Version 5)”, RFC 1510, September 1993. Versions 4 and 5 have also been described by W. Stallings, “Cryptography and Network Security, Principles and Practice”, 2nd edition, p. 323-340. These two versions of Kerberos are briefly described in the following passages.
FIG. 1 shows an overview of a Kerberos system KS according to Kerberos version 4. The Kerberos system KS comprises a client c which can obtain access to the Internet, a Kerberos server KSS in the Internet and a service server V for providing a service for which authentication is required. The Kerberos server KSS comprises an authentication server AS, a ticket-granting server TGS, and a database DB comprising (hashed) passwords of different clients. The client c contains a personal computer (PC), comprising an Input/Output module IOc (such as a modem or a network adapter) for connecting to the Internet, a central processing unit CPUc for processing data and a memory MEMc. The memory has a non-volatile portion for storing applications for controlling the CPUc and a random access memory portion for use in processing data. Additionally, the client c has a user interface UI for interacting with a user. The UI may prompt a user to give a password and may receive the password. In a Kerberos system, the applications together with the personal computer form the client c that can use services of a host (computer) accessible through an insecure network.
The V is a server that provides service to the client c. It authenticates the client c by using a sequence of authentications, in which the client c is first authenticated to the AS to obtain a ticket granting ticket tickettgs. Using the tickettgs the client c can next obtain a service granting ticket ticketv. This ticket can then be used for the service. This procedure will be explained in detail with reference to FIGS. 1 and 2.
In order to work, the Kerberos system should already have a first shared secret (or first authentication key, Kc) known by the client c, the AS and the TGS. A second shared secret (Kv) should be known by the AS, the TGS and the service server V, but not by the client c. These shared secrets are presumed to exist.
For any particular secret to be known by any particular party it is sufficient that the party can, when necessary, obtain the secret, for example by asking the user (party being a client) or by requesting it from the database (party being an AS or TGS). Typically, the TGS and AS are co-located, but in some cases the Kerberos server KSS can also be distributed so that the TGS and AS are not co-located.
Operation of the Kerberos system KS as a sequence of steps is illustrated in FIG. 2. In brief, FIG. 2 shows messaging between the user, client c, authentication server AS, ticket granting server TGS and service server V. For convenience, the notation here will follow that used in the above mentioned publication of Stallings. The steps of FIG. 2 will now be described.
Step 21: The user logs on to the client c and requests a desired service on the service server (host) by sending a login and a service request. To log on, the user enters a client's password Kc that is known by him and the authentication server. The client's password is the first shared secret. From now on, Kc is referred to as a first authentication key.
Step 22: The client c sends to the AS a request for a ticket granting ticket tickettgs. The request comprises the ID of the client c (IDc), the ID of the TGS (IDtgs), and a first time stamp TS1 corresponding to the time when the request was sent.
Step 23: The AS forms a tickettgs using a second authentication key Ktgs known by the AS and the TGS but not by the client c. The tickettgs=EKtgs[Kc,tgs∥IDc∥ADc∥IDtgs∥TS2∥Lifetime2]. E represents an encryption algorithm using a second authentication key Ktgs as its encryption key. Kc,tgs is a first session key formed by the AS (for example, a random key) for use between the client c and the TGS. ADc is the address of the client c, IDtgs is an identity of the TGS, TS2 is second time stamp showing the time of the issue of the tickettgs and Lifetime2 is the time of expiry of the tickettgs. The bars “∥” indicate concatenation. The tickettgs is to be used later for obtaining service granting tickets (ticketv) for using various services. Then the AS encrypts data using the Kc as follows: EKC[Kc,tgs∥IDtgs∥TS2∥Lifetime2] and sends the tickettgs and the encrypted data to the client c.
Step 24: The client c then prompts for the Kc from its user. The user should know the Kc.
Step 25: The user provides the client c with the Kc.
Step 26: Using the Kc and the Kc,tgs, the client c decrypts the encrypted data received from the AS and forms a first client authenticator, authenticatorc1=EKc,tgs[IDc∥ADc∥IDV∥TS3]. IDV is the ID of the V and TS3 is the time of forming the authenticatorc1. As a skilled reader will understand, the client c is only able to derive the Kc,tgs if it knows the Kc. The authenticatorc1 is later used by the TGS to authenticate the client c. The client c then sends a request for a service granting ticket (ticketv) to the TGS. The request contains IDv, tickettgs and authenticatorc1.
Step 27: The TGS forms the ticketV and sends it together with an encrypted second session key Kc,V to the client c. The second session key is encrypted with the first session key Kc,tgs. The ticketV is formed by the TGS using the knowledge of a second shared secret Kv of the V, as follows: ticketV=EKV[Kc,V∥IDc∥ADc∥IDV∥TS4∥Lifetime4], wherein:                Kc,V is a second session key for use between the client c and V,        TS4 is a time stamp showing the time of forming the ticketv, and        Lifetime4 sets the lifetime of the ticketV to prevent replay attacks after the expiry of the lifetime of the ticketv.        
Step 28: The client c sends a service request to the V. The request contains the ticketV and a second client authenticator, authenticatorc2, wherein authenticatorc2=EKc,V[IDc∥ADc∥TS5]. TS5 is a time stamp showing the time of forming the second client authenticator.
Step 29: After the service server V has examined the authenticatorc2, it can authenticate itself to the client c for mutual authentication. This is done by replying with the TS5, incremented by 1 and encrypted with the Kc,V, so that the client c can trust that V is the correct server since it can encrypt with the same Kc,V. The reply is thus EKc,V[TS5+1].
The steps 22 and 23 occur once for each user logon session. The tickettgs is thus valid for the duration of the user logon session (or until it expires). The steps 26 and 27 occur once for each type of service. In other words, for each type of service, a different ticketV is applied for and is granted. The steps 28 and 29 occur once for each service session of a granted service type.
The description of FIG. 2 illustrates how Kerberos can provide centralised authentication to a plurality of different service servers that trust the Kerberos server KSS (the combination of AS and TGS). The KSS has a different second shared secret KV with each V and each V is registered with the KSS.
The system of FIG. 1 represents one realm: For example, a single employer in one country or city owns all the entities.
Kerberos version 5 provides some refinements over version 4, including allowing a plurality of Kerberos realms to inter-operate so that one authentication server AS can grant service granting tickets ticketV to service servers V of different authentication realms.
The operation of a Kerberos system according to Kerberos version 5 will next be described with reference to FIG. 1. In Kerberos version 5, the authentication and key distribution starts with an Authentication Service Exchange procedure, where the client c requests a tickettgs from the AS, and the AS forms and sends the tickettgs and other parameters encrypted with the Kc in response. The tickettgs and the Kc,tgs key will be used as credentials for obtaining service granting tickets (ticketv) for using services. The Authentication Service Exchange is as follows:from c to AS message KRB_AS_REQ=Options∥IDc∥Realmc∥IDtgs∥times∥Nonce1  (1)from AS to c, message KRB_AS_REP=realmc∥IDc∥tickettgs∥EKc[Kc,tgs∥times∥nonce1∥realmtgs∥IDtgs]  (2)where tickettgs=EKtgs[flags∥Kc, tgs∥realmc∥IDc∥ADc∥times]and wherein    options various options used to request that certain flags be set in the returned ticket    flags various message flags for use in the Kerberos version 5 protocol    realmc realm of the client    realmtgs realm of the TGS    times start time, expiration time and renewal time of the tickettgs     nonce1 a random value generated by the client to ensure that the response is fresh (not a copy of an earlier response)
One should bear in mind that different types of fields may be encrypted together, because all the different types are ultimately represented by binary codes (zeros and ones), which can be operated within the same function regardless their origin.
The Kc is used to encrypt the Kc,tgs and other parameters in the KRB_AS_REP message. It should be noted that in Kerberos, anyone can request a tickettgs but only the valid client is able to use it. Because only the valid client knows the Kc, others are not able to decrypt the Kc,tgs which is required when using the tickettgs. In Kerberos, the Kc is only used in the KRB_AS_REP message to encrypt the Kc,tgs and other parameters. Different session keys are used instead of the Kc in all other Kerberos messages.
With the tickettgs and Kc,tgs, the client c is able to obtain new versions of ticketV and Kc,V from the TGS. The new versions can further be used to obtain service from the Vs.
Authentication may also be needed in mobile communications networks. At present, there are various types of mobile communications networks, with different types of authentication procedures. Typically, digital mobile communications networks, such as GSM, provide digital authentication of a subscriber in order to support invoicing of the a network operator running the network. In GSM, the authentication is based on using GSM triplets, which are generated by dedicated Subscriber Identity Modules (SIM) at a subscriber's end and at an Authentication Centre (AuC) of the network operator. The AuC is typically functionality provided by a Home Location Register (HLR) of a GSM network. In GSM, the GSM triplets can be used in a rather relaxed way, so that their order is not strictly fixed. In the forthcoming Universal Mobile Telecommunications System (UMTS) the authentication differs from GSM. An overview of the authentication in UMTS is given in the 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 33.102 V3.6.0 (2000-10), paragraph 6.3, and abstracted in the following:
In UMTS, the user authentication modules are referred to as UMTS subscriber identity modules (USIMs) and the AuC generates authentication vectors, or quintets, which comprise the following components: a random number RAND, an expected response XRES, a cipher key CK, an integrity key IK and an authentication token AUTN. Each authentication vector is good for one authentication. RAND, XRES and CK roughly correspond to RAND, SRES and Kc of GSM, but particularly AUTN and its use form a significant difference over GSM. The AUTN is based, among others, on a sequence number SQN corresponding to a particular authentication vector.
WO00/02406 provides a method, which allows clients in a mobile IP (IP, Internet Protocol) network to generate a Kc by using a Subscriber Identity Module (SIM) of a GSM operator. The GSM operators have databases containing the identities of subscribers and their secret data. In GSM, the secret stored on a SIM is referred to as Ki. The SIM has capability to generate a GSM session key Kgsm, a one-way hashed signed response SRES of a challenge RAND based on the secret Ki. This procedure of WO00/02406 is shown as a series of steps 31 to 37 in FIG. 3.
A security server SS (corresponding to a KSS) sends (step 31) an authentication ID request to a terminal TE1 (corresponds to a client c). The client c responds (step 32) by its International Mobile Subscriber Identity (IMSI). The security server sends (step 33) a security information request to a proxy server. The proxy server acquires (step 34) the security information from a Home Location Register of a GSM operator whose SIM is being used, containing a GSM triplet (Kgsm, RAND and challenge). The proxy server sends (step 35) the GSM triplet to the security server. The security server sends (step 36) the challenge RAND to the client c.
Step 37: The client c forms its own version of the GSM session key Kgsm and SRES corresponding to its Ki and the RAND received. Then the client c sends back the SRES so that the security server can compare it against the SRES it received in the GSM triplet from the proxy server. If the SRES provided by the proxy server and the SRES generated by the client c match, a positive authentication is made and the security server can start using the GSM session key Kgsm as the Kc between the client c and a security server (that is, a Kerberos server).
WO00/02406 combines GSM technology with Kerberos technology. Instead of authenticating a wireless mobile telephone by a GSM network by using the GSM triplets and comparing different responses against each other, the SIM is used for generating a response to a challenge received from a mobile IP network. The response is then sent to the mobile IP network for comparison against the correct answer for the Ki and RAND for detecting that the client c is genuine and is not trying to illegitimately access services using an IMSI of another client.